Network Working Group A. B. Roach 
Reguest for Comments: 4662 B. Campbell 
Category: Standards Track Estacado Systems 

J. Rosenberg 


Cisco Systems 
August 2006 


A Session Initiation Protocol (SIP) Event Notification Extension 
for Resource Lists 


Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and reguests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2006). 


Abstract 


This document presents an extension to the Session Initiation 
Protocol (SIP)-Specific Event Notification mechanism for subscribing 
to a homogeneous list of resources. Instead of sending a SUBSCRIBE 
for each resource individually, the subscriber can subscribe to an 
entire list and then receive notifications when the state of any of 
the resources in the list changes. 
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1. Introduction 


The SIP-specific event notification mechanism [2] allows a user (the 
subscriber) to request to be notified of changes in the state of a 
particular resource. This is accomplished by the subscriber 
generating a SUBSCRIBE request for the resource, which is processed 
by a notifier that represents the resource. 


In many cases, a subscriber has a list of resources they are 
interested in. Without some aggregating mechanism, this will require 
the subscriber to generate a SUBSCRIBE request for each resource 
about which they want information. For environments in which 
bandwidth is limited, such as wireless networks, subscribing to each 
resource individually is problematic. Some specific problems are: 


o Doing so generates substantial message traffic, in the form of the 
initial SUBSCRIBE reguests for each resource and the refreshes of 
each individual subscription. 


o The notifier may insist on low refresh intervals, in order to 
avoid a long-lived subscription state. This means that the 
subscriber may need to generate SUBSCRIBE refreshes faster than it 
would like to or has the capacity to. 


o The notifier may generate NOTIFY requests more rapidly than the 
subscriber desires, causing NOTIFY traffic at a greater volume 
than is desired by the subscriber. 


To solve these problems, this specification defines an extension to 
RFC 3265 [2] that allows for reguesting and conveying notifications 
for lists of resources. A resource list is identified by a URI, and 
it represents a list of zero or more URIs. Each of these URIs is an 
identifier for an individual resource for which the subscriber wants 
to receive information. In many cases, the URI used to identify the 
resource list will be a SIP URI [1]; however, the use of other 
schemes (such as pres: [10]) is also foreseen. 


The notifier for the list is called a "resource list server", or RLS. 
In order to determine the state of the entire list, the RLS will act 
as if it has generated a subscription to each resource in the list. 


The resource list is not restricted to be inside the domain of the 


subscriber. Similarly, the resources in the list are not constrained 
to be in the domain of the resource list server. 
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De 


3: 


Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [5]. 


The following terms are used throughout the remainder of this 
document. 


Back-End Subscription: Any subscription (SIP or otherwise) that an 
RLS creates to learn of the state of a resource. An RLS will 
create back-end subscriptions to learn of the state of a resource 
about which the RLS is not an authority. For back-end 
subscriptions, RLSes act as a subscriber. 


List Subscription: A subscription to a resource list. In list 
subscriptions, RLSes act as the notifier. 


Resource: A resource is any logical entity that has a state or 
states that can be subscribed to. Resources are identified by 
URIs. 


Resource List: A list of zero or more resources that can have their 
individual states subscribed to with a single subscription. 


RLMI: Resource List Meta-Information. RLMI is a document that 
describes the state of the virtual subscriptions associated with a 
list subscription. 


RLS: Resource List Server. RLSes accept subscriptions to resource 
lists and send notifications to update subscribers of the state of 
the resources in a resource list. 


Virtual Subscription: A Virtual Subscription is a logical construct 
within an RLS that represents subscriptions to the resources in a 
resource list. For each list subscription it services, an RLS 
creates at least one virtual subscription for every resource in 
the resource list being subscribed to. In some cases, such as 
when the RLS is not the authority for the state of the resource, 
this virtual subscription will be associated with a back-end 
subscription. In other cases, such as when the RLS is the 
authority for the state of the resource, the virtual subscription 
will not have a corresponding back-end subscription. 


Overview of Operation 


This section provides an overview of the typical mode of operation of 
this extension. It is not normative. 
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When users wish to subscribe to the resource of a list of resources, 
they can use the mechanisms described in this specification. The 
first step is the creation of a resource list. This resource list is 
represented by a SIP URI. The list contains a set of URIs, each of 
which represents a resource for which the subscriber wants to receive 
information. The resource list can exist in any domain. The list 
could be manipulated through a web page, through a voice response 
system, or through some other protocol. The specific means by which 
the list is created and maintained is outside the scope of this 
specification. 


To learn the resource state of the set of elements on the list, the 
user sends a single SUBSCRIBE reguest targeted to the URI of the 
list. This will be routed to an RLS for that URI. The RLS acts as a 
notifier, authenticates the subscriber, and accepts the subscription. 


The RLS may have direct information about some or all of the 
resources specified by the list. If it does not, it could subscribe 
to any non-local resources specified by the list resource. 


Note that subscriptions to non-local resources may or may not be SIP 
subscriptions; any mechanism for determining such information may be 
employed. This document uses the term "back-end subscription" to 
refer to such a subscription, regardless of whether SIP is used to 
establish and service it. 


As the state of resources in the list change, the RLS generates 
notifications to the list subscribers. The RLS can, at its 
discretion, buffer notifications of resource changes and send the 
resource information to the subscriber in batches, rather than 
individually. This allows the RLS to provide rate limiting for the 
subscriber. 


The list notifications contain a body of type multipart/related. The 
root section of the multipart/related content is an XML document that 
provides meta-information about each resource present in the list. 
The remaining sections contain the actual state information for each 
resource. 


4. Operation of List Subscriptions 


The event list extension acts, in many ways, like an event template 
package. In particular, any single list subscription must be 
homogeneous with respect to the underlying event package. In other 
words, a single list subscription can apply only one event package to 
all the resources in the resource list. 
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Note that it is perfectly valid for an RLS to allow multiple 
subscriptions to the same list to use differing event packages. 


The key difference between a list subscription and templates in 
general is that support for list subscriptions indicates support for 


arbitrary nesting of list subscriptions. In other words, elements 
within the list may be atomic elements, or they may be lists 
themselves. 


The conseguence of this is that subscription to a URI that represents 
a list actually results in several virtual subscriptions to a tree of 
resources. The leaf nodes of this tree are virtual subscriptions of 
the event type given in the "Event" header field; all other nodes in 
the tree are list subscriptions that are serviced as described in 
this section and its subsections. 


Keep in mind that these virtual subscriptions are not literal SIP 
subscriptions (although they may result in SIP subscriptions, 
depending on the RLS implementation). 


4.1. Negotiation of Support for Resource Lists 


This specification uses the SIP option tag mechanism for negotiating 
support for the extension defined herein. Refer to RFC 3261 [1] for 
the normative description of processing of the "Supported" and 
"Require" header fields and the 421 (Extension Required) response 
code. 


A non-normative description of the implications of the use of 
option tags follows. 

Any client that supports the event list extension will include an 
option tag of "eventlist" in a "Supported" header field of every 
SUBSCRIBE message for a subscription for which it is willing to 
process a list. If the subscription is made to a URI that 
represents a list, the RLS will include "eventlist" in a "Require" 
header field of the response to the SUBSCRIBE, and in all NOTIFY 
messages within that subscription. 


Use of "Reguire: eventlist" in NOTIFY messages is applied by the 
notifier to satisfy the RFC 3261 reguirement that a UAC MUST 
insert a Reguire header field into a reguest if the UAC wishes to 
insist that a UAS understand an extension in order to process the 
reguest. Because the NOTIFY would not be usable without applying 
the eventlist option, the notifier is obligated to include it. 


Including "eventlist" in a "Reguire" header field in a SUBSCRIBE 


reguest serves no purpose except to break interoperability in certain 
cases, and is conseguently NOT RECOMMENDED. 
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Sending of "Supported: eventlist" in a NOTIFY message is meaningless 
and silly. Implementations SHOULD NOT include "Supported: eventlist" 
in any reguests except for SUBSCRIBE. 


There is nothing in a SIP URI that indicates whether it represents a 
list of resources or a single resource. Therefore, if a subscriber 
sends a reguest to a URI that represents a list resource but does not 
include a Supported header field listing the "eventlist" token, the 
notifier will typically return a 421 (Extension Reguired) response 
code. RFC 3261 [1] advises that servers avoid returning a 421 and 
instead attempt to process the reguest without the extension. 
However, in this case, the URI fundamentally represents a list 
resource, and therefore the subscription cannot proceed without this 
extension. 


4.2. Subscription Duration 


Since the primary benefit of the resource list server is to reduce 
the overall messaging volume to a subscriber, it is RECOMMENDED that 
the subscription duration to a list be reasonably long. The default, 
when no duration is specified, is taken from the underlying event 
package. Of course, the standard techniques [2] can be used to 
increase or reduce this amount. 


4.3. NOTIFY Bodies 


An implementation compliant to this specification MUST support the 
multipart/related and application/rlmi+xml MIME types. These types 
MUST be included in an Accept header sent in a SUBSCRIBE message, in 
addition to any other types supported by the client (including any 
types reguired by the event package being used). 


4.4. RLS Processing of SUBSCRIBE Requests 


Once the subscriber is authenticated, the RLS performs authorization 


per its local policy. In many cases, each resource list is 
associated with a particular user (the one who created it and manages 
the set of elements in it), and only that user will be allowed to 


subscribe. Of course, this mode of operation is not inherent in the 
use of resource lists, and an RLS can use any authorization policy it 
chooses. 


4.5. RLS Generation of NOTIFY Requests 


This specification leaves the choice about how and when to generate 
NOTIFY requests at the discretion of the implementor. One of the 
differentiators between various RLS implementations is the means by 
which they aggregate, rate-limit, or optimize the way in which 
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notifications are generated. As a baseline behavior, the RLS MAY 
generate a NOTIFY to the RLS subscriber whenever the state of any 
resource on the list changes. 


It is important to understand that any given subscription is a 
subscription either to a single resource or to a list of resources. 
This nature (single resource versus list of resources) cannot change 
during the duration of a single subscription. In particular, this 
means that RLSes MUST NOT send NOTIFY messages that do not contain 
RLMI for a subscription if they have previously sent NOTIFY messages 
in that subscription containing RLMI. Similarly, RLSes MUST NOT send 
NOTIFY messages that do contain RLMI for a subscription if they have 
previously sent NOTIFY messages in that subscription which do not. 


List representations necessarily contain RLMI documents for two 
reasons. Importantly, they identify the resource to which the 
event state corresponds. Many state syntaxes do not fully 
identify the resource to which the state applies, or they may 
identify the resource in a different way than it is represented in 
the list; for example, PIDF documents may contain resource URIs 
that are not identical to the URI used to retrieve them. Further, 
RLMI documents serve to disambiguate multiple instances of a 
single resource. 


See Section 5 for a detailed definition of the syntax used to convey 
the state of resource lists. For the purposes of the following 
discussion, it is important to know that the overall list contains 
zero or more resources, and that the resources contain zero or more 


instances. Each instance has a state associated with it (pending, 
active, or terminating) representing the state of the virtual 
subscription. 


Notifications contain a multipart document, the first part of which 
always contains meta-information about the list (e.g., membership, 
state of the virtual subscription to the resource). Remaining parts 
are used to convey the actual state of the resources listed in the 
meta-information. 


The "state" attribute of each instance of a resource in the 
meta-information is set according to the state of the virtual 
subscription. The meanings of the "state" attribute are described in 
RFC 3265 [2]. 


If an instance of a resource was previously reported to the 
subscriber but is no longer available (i.e., the virtual subscription 
to that instance has been terminated), the resource list server 
SHOULD include that resource instance in the meta-information in the 
first NOTIFY message sent to the subscriber following the instance’s 
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unavailability. The RLS MAY continue to do so for future 
notifications. 


When sending information for a terminated resource instance, the RLS 
indicates a state of "terminated" and an appropriate reason value. 
Valid reason values and their meanings are described in RFC 3265 [2]. 
If the RLS will attempt to recover the resource state again at some 
point in the future (e.g., when the reason in the meta-information is 
"probation"), then the instance of the resource SHOULD remain in the 
meta-information until the instance state is available, or until the 
RLS gives up on making such state available. 


When the first SUBSCRIBE message for a particular subscription is 
received by an RLS, the RLS will often not know state information for 
all the resources specified by the resource list. For any resource 
for which state information is not known, the corresponding "uri" 
attribute will be set appropriately, and no <instance> elements will 
be present for the resource. 


For an initial notification, sections corresponding to resources for 
which the RLS does have state will be populated with appropriate data 
(subject, of course, to local policy decisions). This will often 
occur if the resource list server is co-located with the server for 
one or more of the resources specified on the list. 


Immediate notifications triggered as a result of subsequent SUBSCRIBE 
messages SHOULD include an RLMI document in which the full state is 
indicated. The RLS SHOULD also include state information for all 
resources in the list for which the RLS has state, subject to policy 
restrictions. This allows the subscriber to refresh their state, and 
to recover from lost notifications. 


4.6. Subscriber Processing of NOTIFY Requests 


Notifications for a resource list can convey information about a 


subset of the list elements. This means that an explicit algorithm 
needs to be defined in order to construct coherent and consistent 
state. 


The XML document present in the root of the multipart/related 
document contains a <resource> element for some or all of the 
resources in the list. Each <resource> element contains a URI that 
uniguely identifies the resource to which that section corresponds. 
When a NOTIFY arrives, it can contain full or partial state (as 
indicated by the "fullState" attribute of the top-level <list> 
element). If full state is indicated, then the recipient replaces 
all state associated with the list with the entities in the NOTIFY 
body. If full state is not indicated, the recipient of the NOTIFY 
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updates information for each identified resource. Information for 
any resources that are not identified in the NOTIFY is not changed, 
even if they were indicated in previous NOTIFY messages. See 
Section 5.6 for more information. 


When full state is indicated, note that it applies only to the 
RLMI document in which it occurs. In particular, one of the 
<resource> elements in the document may in turn refer to another 
list of resources. Any such sub-lists will be detailed in their 
own RLMI documents, which may or may not have full state 
indicated. 


Further note that the underlying event package may have its own 
rules for compositing partial state notification. When processing 
data related to those packages, their rules apply (i.e., the fact 
that they were reported as part of a list does not change their 
partial notification semantics). 


Finally, note that as a conseguence of the way in which resource 
list subscriptions work, polling of resource state may not be 
particularly useful. While such polls will retrieve the resource 
list, they will not necessarily contain state for some or all of 
the resources on the list. 


4.7. Handling of Forked Requests 


Forking makes little sense with subscriptions to event lists, since 
the whole idea is a centralization of the source of notifications. 
Therefore, a subscriber to a list MUST NOT install multiple 
subscriptions when the initial reguest is forked. If multiple 
responses are received, they are handled using the technigues 
described in Section 4.4.9 of RFC 3265 [2]. 


4.8. Rate of Notifications 


One potential role of the RLS is to perform rate limitations on 
behalf of the subscriber. As such, this specification does not 
mandate any particular rate limitation, and rather leaves that to the 
discretion of the implementation. 


5. Using multipart/related to Convey Aggregate State 
In order to convey the state of multiple resources, the list 
extension uses the "multipart/related" mime type. The syntax for 


multipart/related is defined in "The MIME Multipart/Related Content- 
type" [4]. 
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5.1. XML Syntax 


The root document of the multipart/related body MUST be a Resource 
List Meta-Information (RLMI) document. It is of the type 
"application/rlmi+xml". This document contains the meta-information 
for the resources contained in the notification. The schema for this 
XML document is given below. 


<?xml version="1.0" encoding="UTF-8" ?> 
<xs:schema targetNamespace="urn:ietf:params:xml:ns:rlmi" 
elementFormDefault="qualified" 
xmlns="urn:ietf:params:xml:ns:rlmi" 
xmlns:xs="http://www.w3.org/2001/XMLSchema"> 
<xs: import namespace="http://www.w3.org/XML/1998/namespace" 
schemaLocation="http://www.w3.0rg/2001/xml.xsd"/> 
<xs:element name="list"> 
<xs:complexType> 
<xs:sequence> 
<xs:element ref="name" minOccurs="0" 
maxOccurs="unbounded" /> 
<xs:element ref="resource" minOccurs="0" 
maxOccurs="unbounded" /> 
</xs:sequence> 
<xs:attribute name="uri" type="xs:anyURI" use="required" /> 
<xs:attribute name="version" type="xs:unsignedInt" 
use="required" /> 
<xs:attribute name="fullState" type="xs:boolean" 
use="required" /> 
<xs:attribute name="cid" type="xs:string" use="optional" /> 
<xs:anyAttribute processContents="lax" /> 
</xs:complexType> 
</xs:element> 
<xs:element name="resource"> 
<xs:complexType> 
<xs:seguence> 
<xs:element ref="name" minOccurs="0" 
maxOccurs="unbounded" /> 
<xs:element ref="instance" minOccurs="0" 
maxOccurs="unbounded" /> 
</xs:seguence> 
<xs:attribute name="uri" type="xs:anyURI" use="reguired" /> 
<xs:anyAttribute processContents="lax" /> 
</xs:complexType> 
</xs:element> 
<xs:element name="instance"> 
<xs:complexType> 
<xs:sequence> 
<xs:any minOccurs="0" maxOccurs="unbounded" 
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processContents="lax" /> 
</xs:sequence> 
<xs:attribute name="id" type="xs:string" use="required" /> 
<xs:attribute name="state" use="required"> 
<xs:simpleType> 
<xs:restriction base="xs:string"> 
<xs:enumeration value="active" /> 
<xs:enumeration value="pending" /> 
<xs:enumeration value="terminated" /> 
</xs:restriction> 
</xs:simpleType> 
</xs:attribute> 
<xs:attribute name="reason" type="xs:string" 
use="optional" /> 
<xs:attribute name="cid" type="xs:string" use="optional" /> 
<xs:anyAttribute processContents="lax" /> 
</xs:complexType> 
</xs:element> 
<xs:element name="name"> 
<xs :complexType> 
<xs:simpleContent> 
<xs:extension base="xs:string"> 
<xs:attribute ref="xml:lang" use="optional"/> 
</xs:extension> 
</xs:simpleContent> 
</xs:complexType> 
</xs:element> 
</xs:schema> 


An example of a document formatted using this schema follows. 


<?xml version="1.0"?> 
<list xmlns="urn:ietf:params:xml:ns:rlmi" 
uri="sip:adam-friendsGlists.vancouver.example.com" 
version="7" fullState="true"> 
<name xml:lang="en">Buddy List</name> 
<name xml:lang="fr">Liste d’ amis</name> 
<resource uri="sip:bob@vancouver.example.com"> 
<name>Bob Smith</name> 
<instance id="juwigmtboe" state="active" 
cid="12345.aaa@vancouver.example.com"/> 
</resource> 
<resource uri="sip:dave@vancouver.example.com"> 
<name>Dave Jones</name> 
<instance id="hqzsuxtfyq" state="active" 
cid="12345.aab@vancouver.example.com"/> 
</resource> 
<resource uri="Sip: jim@vancouver.example.com"> 
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<name>Jim</name> 
<instance id="oflzxazuvg" state="terminated" 
reason="rejected" /> 


</resource> 
<resource uri="sip:ed@vancouver.example.com"> 
<name>Ed</name> 
<instance id="grqhzsppxb" state="pending"/> 
</resource> 
</list> 


5.2. List Attributes 


The <list> element present in a list notification MUST contain three 
attributes. 


The first mandatory <list> attribute is "uri", which contains the uri 
that corresponds to the list. Typically, this is the URI to which 
the SUBSCRIBE request was sent. 


The second mandatory <list> attribute is "version", which contains a 
number from 0 to 232-1. This version number MUST be 0 for the first 
NOTIFY message sent within a subscription, and MUST increase by 
exactly one for each subsequent NOTIFY sent within a subscription. 


The third mandatory attribute is "fullState". The "fullState" 
attribute indicates whether the NOTIFY message contains information 
for every resource in the list. If it does, the value of the 
attribute is "true" (or "1"); otherwise, it is "false" (or "0"). The 


first NOTIFY sent in a subscription MUST contain full state, as must 
the first NOTIFY sent after receipt of a SUBSCRIBE request for the 
subscription. 


Finally, <list> elements MAY contain a "cid" attribute. If present, 
the "cid" attribute identifies a section within the multipart/related 
body that contains aggregate state information for the resources 
contained in the list. The definition of such aggregate information 
is outside the scope of this document and will be defined on a per- 
package basis, as needed. The cid attribute is the Content-ID for 
the corresponding section in the multipart body. 


The cid attribute MUST refer only to top-level parts of the 


multipart/related document for which the RLMI document in which it 
appears is the root. See Section 5.5 for an example. 
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5.3. Resource Attributes 


The resource list contains one <resource> element for each resource 
being reported in the notification. These resource elements contain 
attributes that identify meta-data associated with each resource. 


The "uri" attribute identifies the resource to which the <resource> 
element corresponds. Typically, this will be a SIP URI that, if 
subscribed to, would return the state of the resource. This 
attribute MUST be present. 


5.4. Name Attributes 


Each list and resource element contains zero or more name elements. 
These name elements contain human-readable descriptions or names for 


the resource list or resource. The contents of these elements are 
somewhat analogous to the "Display Name" present in the SIP name-addr 
element. 


Name elements optionally contain the standard XML "xml:lang" 
attribute. The "xml:lang" attribute, if present, specifies the 
language of the human-readable name. If this attribute is present, 
it MUST contain a valid language tag. Language tags are defined in 
RFC 3066 [6]. The language tag assists applications in determining 
which of potentially several name elements should be rendered to the 
user. 


5.5. Instance Attributes 


Each resource element contains zero or more instance elements. These 
instance elements are used to represent a single notifier for the 
resource. For event packages that allow forking, multiple virtual 
subscriptions may exist for a given resource. Multiple virtual 
subscriptions are represented as multiple instance elements in the 


corresponding resource element. For subscriptions in which forking 
does not occur, at most one instance will be present for a given 
resource. 


The "id" attribute contains an opague string used to uniguely 
identify the instance of the resource. The "id" attribute is unique 
only within the context of a resource. Construction of this string 
is an implementation decision. Any mechanism for generating this 
string is valid, as long as unigueness within the resource is 
assured. 


The "state" attribute contains the subscription state for the 


identified instance of the resource. This attribute contains one of 
the values "active", "pending", or "terminated". The meanings for 
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these values are as defined for the "Subscription-State" header field 
in RFC 3265 [2]. 


If the "state" attribute indicates "terminated", then a "reason" 


attribute MUST also be present. This "reason" attribute has the same 
values and meanings as those given for the "reason" parameter on the 
"Subscription-State" header field in RFC 3265 [2]. Note that the 


"reason" attribute is included for informational purposes; the list 
subscriber is not expected to take any automated actions based on the 
reason value. 


Finally, the "cid" attribute, which MUST be present if the "state" 
attribute is "active", identifies the section within the 
multipart/related body that contains the actual resource state. This 
state is expressed in the content type defined by the event package 
for conveying state. The cid attribute is the Content-ID for the 
corresponding section in the multipart body. 


The cid attribute MUST refer only to top-level parts of the 
multipart/related document for which the RLMI document in which it 
appears is the root. 
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For example, consider a multipart/related document containing 
three parts; we’ll label these parts A, B, and C. Part A is type 
application/rlmi+xml, part B is type multipart/related, and part C 
is type application/pidf+xml. Part B is in turn a document 
containing three parts: D, E, and F. Part D is of type 
application/rlmi+xml, and parts E and F are of type 
application/pidf+xml. 


| | 
| | 
| | 
| | 
| | 
| | 
PES AEE ale 
| | | Part D: application/rlmi+xml | | 
[| EE mms eee RSR Sms o + | | 
| | | Part E: application/pidf+xml Al 
|| 1 EE + | | 

| Part F: application/pidf+xml | 

fe eee es ee EA + 
| | | | 
| +--------------------------------------- + | 
| | Part C: application/pidf+xml | | 
| +--------------------------------------- + | 
| | 
4------------------------------------------- + 


Any "cid" attributes in document A must refer only to parts B or 
C. Referring to parts D, E, or F would be illegal. Similarly, 
any "cid" attributes in document D must refer only to parts E or 
F. Referring to any other parts would be illegal. 

Also note that the subscription durations of any back-end 
subscriptions are not propagated into the meta-information state 
in any way. 


5.6. Constructing Coherent Resource State 


The resource list subscriber maintains a table for each resource 


list. The table contains a row for each resource in the resource 
list. Each row is indexed by the URI for that resource. That URI is 
obtained from the "uri" attribute on each <resource> element. The 


contents of each row contain the state of that resource as conveyed 
in the resource document. 


Roach, et al. Standards Track [Page 16] 


RFC 4662 SIP Event Lists August 2006 


For resources that provide versioning information (which is mandated 
by [2] for any formats that allow partial notification), each row 
also contains a resource state version number. The version number of 
the row is initialized with the version specified in the first 
document received, as defined by the corresponding event package. 
This value is used when comparing versions of partial notifications 
for a resource. 


The processing of the resource list notification depends on whether 
it contains full or partial state. 


5.6.1. Processing Full State Notifications 


If a notification contains full state, indicated by the <list> 
attribute "fullState" set to "true", the notification is used to 
update the table. A check is first made to ensure that the "version" 
attribute of the <list> attribute in the received message is greater 
than the local version number. If not, the received document is 
discarded without any further processing. Otherwise, the contents of 
the resource-list table are flushed and repopulated from the contents 
of the document. A new row in the table is created for each 
"resource" element. 


5.6.2. Processing Partial State Notifications 


If a notification contains partial state, indicated by the <list> 
attribute "fullState" set to "false", a check is made to ensure that 
no list notifications have been lost. The value of the local version 
number (the "version" attribute of the <list> element) is compared to 
the version number of the new document. 


o If the value in the new document is exactly one higher than the 
local version number, the local version number is increased by 
one, and the document is processed as described below. 


o If the version in the document is more than one higher than the 
local version number, the local version number is set to the value 
in the new document, and the document is processed as described 
below. The list subscriber SHOULD also generate a refresh request 
to trigger a full state notification. 


o If the version in the document is less than or egual to the local 
version, the document is discarded without any further processing. 


For each resource listed in the document, the subscriber checks to 
see whether a row exists for that resource. This check is done by 
comparing the Resource-URI value with the URI associated with the 
row. If the resource doesn't exist in the table, a row is added, and 
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its state is set to the information from that "resource" element. If 
the resource does exist, its state is updated to be the information 
from that "resource" element, as described in the definition of the 


event package. If a row is updated or created such that its state is 
now "terminated," that entry MAY be removed from the table at any 
time. 


6. Example 


This section gives an example call flow. It is not normative. If a 
conflict arises between this call flow and the normative behavior 
described in this or any other document, the normative descriptions 
are to be followed. 


In this particular example, we reguest a subscription to a nested 
presence list. The subscriber’s address-of-record is 
"sip:adam@vancouver.example.com", and the name of the nested list 
resource that we are subscribing to is called 
"sip:adam-buddies@pres.vancouver.example.com". The underlying event 
package is "presence", described by [8]. 


In this example, the RLS has information to service some of the 
resources on the list, but must consult other servers to retrieve 


information for others. The implementation of the RLS in this 
example uses the SIP SUBSCRIBE/NOTIFY mechanism to retrieve such 
information. 
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Terminal pres.vancouver.example.com pres.stockholm.example.org 
| | pres.dallas.example.net | 


1 |---SUBSCRIBE---> 

2 |<----- 200——===-= 

3 |<----NOTIFY----- | | | 

4 |------ 200------ > | | | 

5 | | ---SUBSCRIBE--->| | 

6 | |<----- 200------- | | 

7 | <----NOTIFY----- | 

S| as 200------ > 

9 | |------------ SUBSCRIBE----------- >| 

10| |<-------------- 200--------------- | 

11| |<------------- NOTIFY------------- 

12 | | --------------- 200-------------- > | 

13 | <----NOTIFY----- | | | 

14 | ------ 200------ > | | 

Ta We initiate the subscription by sending a SUBSCRIBE message to 
our local RLS. (There is no reason that the RLS we contact has 
to be in our domain, of course). Note that we must advertise 


support for application/rlmi+xml and multipart/related because 
we support the eventlist extension, and that we must advertise 
application/pidf+xml because we are requesting a subscription to 
presence. 


Terminal -> Local RLS 


SUBSCRIBE sip:adam-buddies@pres.vancouver.example.com SIP/2.0 

Via: SIP/2.0/TCP terminal.vancouver.example.com; 
branch=z9hG4bKwYb60REiCL 

Max-Forwards: 70 

To: <sip:adam-buddies@pres.vancouver.example.com> 

From: <sip:adam@vancouver.example.com>;tag=ie4hbb8t 

Call-ID: cdB34qLToC@terminal.vancouver.example.com 

CSeq: 322723822 SUBSCRIBE 

Contact: <sip:terminal.vancouver.example.com> 

Event: presence 

Expires: 7200 

Supported: eventlist 

Accept: application/pidf+xml 

Accept: application/rlmi+xml 

Accept: multipart/related 

Accept: multipart/signed 

Accept: application/pkcs7-mime 

Content-Length: 0 
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Dr The Local RLS completes the SUBSCRIBE transaction. Note that 
authentication and authorization would normally take place at 
this point in the call flow. Those steps are omitted for 
brevity. 


Local RLS -> Terminal 


SIP/2.0 200 OK 

Via: SIP/2.0/TCP terminal.vancouver.example.com; 
branch=z9hG4bKwYb60REiCL 

To: <sip:adam-buddies@pres.vancouver.example.com>; tag=zpNctbZq 

From: <sip:adam@vancouver.example.com>;tag=ie4hbb8t 

Call-ID: cdB34qLToC@terminal.vancouver.example.com 

CSeq: 322723822 SUBSCRIBE 

Contact: <sip:pres.vancouver.example.com> 

Expires: 7200 

Require: eventlist 

Content-Length: 0 


Sa As is required by RFC 3265 [2], the RLS sends a NOTIFY 
immediately upon accepting the subscription. In this example, 
we are assuming that the local RLS is also an authority for 
presence information for the users in the 
"vancouver .example.com" domain. The NOTIFY contains an RLMI 
document describing the entire buddy list (initial notifies 
require full state), as well as presence information for the 
users about which it already knows. Note that, since the RLS 
has not yet retrieved information for some of the entries on the 
list, those <resource> elements contain no <instance> elements. 


Local RLS -> Terminal 


NOTIFY sip:terminal.vancouver.example.com SIP/2.0 
Via: SIP/2.0/TCP pres.vancouver.example.com; 
branch=z 9hG4bKMgRenTETmm 

Max-Forwards: 70 

From: <sip:adam-buddies@pres.vancouver.example.com>; tag=zpNctbZq 

To: <sip:adam@vancouver.example.com>;tag=ie4hbb8t 

Call-ID: cdB34qLToC@terminal.vancouver.example.com 

CSeq: 997935768 NOTIFY 

Contact: <sip:pres.vancouver.example.com> 

Event: presence 

Subscription-State: active; expires=7200 

Require: eventlist 

Content-Type: multipart/related;type="application/rlmi+xml"; 
start="<nXYxAE@pres.vancouver.example.com>"; 
boundary="50UBfW7LSCVLtggUPe5z" 

Content-Length: 1560 
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--50UBfW7LSCVLtggUPe5z 

Content-Transfer-Encoding: binary 

Content-ID: <nXYxAEGpres.vancouver.example.com> 
Content-Type: application/rlmi+xml;charset="UTF-8" 


<?xml version="1.0" encoding="UTF-8"?> 
<list xmlns="urn:ietf:params:xml:ns:rlmi" 
uri="sip:adam-friends@pres.vancouver.example.com" 
version="1" fullState="true"> 
<name xml:lang="en">Buddy List at COM</name> 
<name xml:lang="de">Liste der Freunde an COM</name> 
<resource uri="sip:bob@vancouver.example.com""> 
<name>Bob Smith</name> 
<instance id="juwigmtboe" state="active" 
cid="bUZBsM@pres.vancouver.example.com"/> 
</resource> 
<resource uri="sip:davelvancouver.example.com"> 
<name>Dave Jones</name> 
<instance id="hqzsuxtfyq" state="active" 
cid="ZvSvkz@pres.vancouver.example.com"/> 
</resource> 
<resource uri="Sip:ed@dallas.example.net"> 
<name>Ed at NET</name> 
</resource> 
<resource uri="sip:adam-friends@stockholm.example.org"> 
<name xml:lang="en">My Friends at ORG</name> 
<name xml:lang="de">Meine Freunde an ORG</name> 
</resource> 
</list> 


--50UBfW7LSCVLtggUPe5z 

Content-Transfer-Encoding: binary 

Content-ID: <bUZBsM@pres.vancouver.example.com> 
Content-Type: application/pidf+xml;charset="UTF-8" 


<?xml version="1.0" encoding="UTF-8"?> 
<presence xmlns="urn:ietf:params:xml:ns:pidf" 
entity="sip:bob@vancouver.example.com"> 
<tuple id="sg89ae"> 
<status> 
<basic>open</basic> 
</status> 
<contact priority="1.0">sip:bob@vancouver.example.com</contact> 
</tuple> 
</presence> 


--50UBfW7LSCVLtggUPe5z 
Content-Transfer-Encoding: binary 
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Content-ID: <ZvSvkz@pres.vancouver.example.com> 
Content-Type: application/pidf+xml;charset="UTF-8" 


<?xml version="1.0" encoding="UTF-8"?> 
<presence xmlns="urn:ietf:params:xml:ns:pidf" 
entity="sip:dave@vancouver.example.com"> 
<tuple id="slie74"> 
<status> 
<basic>closed</basic> 
</status> 
</tuple> 
</presence> 


--50UBfW7LSCVLtggUPe5z-- 
4. The terminal completes the transaction. 
Terminal -> Local RLS 


SIP/2.0 200 OK 
Via: SIP/2.0/TCP pres.vancouver.example.com; 
branch=z 9hG4bKMgRenTETmm 
From: <sip:adam-buddies@pres.vancouver.example.com>;tag=zpNctbzq 
To: <sip:adam@vancouver.example.com>;tag=ie4hbb8t 
Call-ID: cdB34gLToCfterminal.vancouver.example.com 
CSeg: 997935768 NOTIFY 
Contact: <sip:terminal.vancouver.example.com> 
Content-Length: 0 


BG In order to service the subscription, the local RLS subscribes 
to the state of the resources. In this step, the RLS attempts 
to subscribe to the presence state of the resource 
"sip:ed@dallas.example.net". Since the local RLS knows how to 
receive notifications for list subscriptions, it includes the 
"Supported: eventlist" header field in its request. Although 
the linkage between this subscription and the one sent by the 
terminal is left up to the application, this message 
demonstrates some reasonable behavior by including "Accept" 
header fields for all the body types it knows the subscriber 
(Terminal) supports. This is safe to do, since the local RLS 
will only pass these formats through to the subscriber and does 
not need to actually understand them. 


Local RLS -> Presence Server in dallas.example.net 
SUBSCRIBE sip:ed@dallas.example.net SIP/2.0 


Via: SIP/2.0/TCP pres.vancouver.example.com; 
branch=z 9hG4bKMEyGjdG1LH 


Roach, et al. Standards Track [Page 22] 


RFC 4662 SIP Event Lists August 2006 


Max-Forwards: 70 

To: <sip:ed@dallas.example.net> 

From: <sip:adam@vancouver.example.com>; tag=aM5icQu9 

Call-ID: Ugwz5ARxNw@pres.vancouver.example.com 

CSeq: 870936068 SUBSCRIBE 

Contact: <sip:pres.vancouver.example.com> 

Identity: Tm8sIHRoaXMgaXNuJ30gYSByZWFsIGNIcnOuIFlvdSBvn 
Zpb3VzbHkgaGF2ZSB0aW11IHRvIGtpbGwuIEkKc3VnZ2V 
zdCBodHRwOi8vd3d3LmhvbWVzdGFycnVubmVyLmNvbS8K 

Identity-Info: https://vancouver.example.com/cert 

Event: presence 

Expires: 3600 

Supported: eventlist 

Accept: application/pidf+xml 

Accept: application/rlmi+xml 

Accept: multipart/related 

Accept: multipart/signed 

Accept: application/pkcs7-mime 

Content-Length: 0 


6. The Presence Server in dallas.example.net completes the 
SUBSCRIBE transaction. Note that authentication would normally 
take place at this point in the call flow. This step is omitted 
for brevity. 


Presence Server in dallas.example.net -> Local RLS 


SIP/2.0 200 OK 

Via: SIP/2.0/TCP pres.vancouver.example.com; 
branch=z9hG4bKMEyGjdG1LH 

To: <sip:ed@dallas.example.net>;tag=e45TmHTh 

From: <sip:adam@vancouver.example.com>;tag=aM5icQu9 

Call-ID: Ugwz5ARxNw@pres.vancouver.example.com 

CSeq: 870936068 SUBSCRIBE 

Contact: <sip:dallas.example.net> 

Expires: 3600 

Content-Length: 0 


7. In this example, we assume that the server at dallas.example.net 
doesn’t have enough authorization information to reject or 
accept our subscription. The initial notify, therefore, 
contains a "Subscription-State" of "pending". Presumably, the 
party responsible for accepting or denying authorization for the 
resource is notified of this change; however, those steps are 
not included in this call flow for brevity. 
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Presence Server in dallas.example.net -> Local RLS 


NOTIFY sip:pres.vancouver.example.com SIP/2.0 

Via: SIP/2.0/TCP pres.dallas.example.net; 
branch=z9hG4bKfwpklPxmrW 

Max-Forwards: 70 

From: <sip:ed@dallas.example.net>;tag=e45TmHTh 

To: <sip:adam@vancouver.example.com>;tag=aM5icQu9 

Call-ID: Ugwz5ARxNw@pres.vancouver.example.com 

CSeq: 1002640632 NOTIFY 

Contact: <sip:dallas.example.net> 

Subscription-State: pending; expires=3600 

Event: presence 

Require: eventlist 

Content-Length: 0 


8. The local RLS completes the NOTIFY transaction. Note that, at 
this point, the Local RLS has new information to report to the 
subscriber. Whether it chooses to report the information 
immediately or spool it up for later delivery is completely up 
to the application. For this example, we assume that the RLS 
will wait for a short period of time before doing so, in order 
to allow the subscriptions it sent out sufficient time to 
provide useful data. 


Local RLS -> Presence Server in dallas.example.net 


SIP/2.0 200 OK 

Via: SIP/2.0/TCP pres.dallas.example.net; 
branch=z9hG4bKfwpklPxmrW 

From: <sip:ed@dallas.example.net>;tag=e45TmHTh 

To: <sip:adam@vancouver.example.com>;tag=aM5icQu9 

Call-ID: Ugwz5ARxNw@pres.vancouver.example.com 

CSeq: 1002640632 NOTIFY 

Contact: <sip:pres.vancouver.example.com> 

Content-Length: 0 


9 The Local RLS subscribes to the state of the other non-local 
resource. 


Local RLS -> RLS in stockholm.example.org 


SUBSCRIBE sip:adam-friends@stockholm.example.org SIP/2.0 

Via: SIP/2.0/TCP pres.vancouver.example.com; 
branch=z9hG4bKFSrAF8CZFL 

Max-Forwards: 70 

To: <sip:adam-friends@stockholm.example.org> 

From: <sip:adam@vancouver.example.com>;tag=al2eztNf 
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Call-ID: kBg5XhtZLNGpres.vancouver.example.com 


CSeg: 


980774491 SUBSCRIBE 


Contact: <sip:pres.vancouver.example.com> 
Identity: Tm90IGEgcmVhbCBzaWduYXR1cmUsIGVpdGhlci4g02VydGFp 


bmx5IHlvdSBoYXZ1IGJIdHRIcgp0aGluZ3MgdG8gYmUgZG9p 
bmcuIEhhdmUgeW91IGZpbmlzaGVkIHlvdXIgUkxTIH11dD8K 


Identity-Info: https://vancouver.example.com/cert 
Event: presence 

Expires: 3600 

Supported: eventlist 

Accept: application/pidf+xml 

Accept: application/rlmi+xml 

Accept: multipart/related 

Accept: multipart/signed 

Accept: application/pkcs7-mime 

Content-Length: 0 


10. 


The RLS in stockholm.example.org completes the SUBSCRIBE 


transaction. Note that authentication would normally take place 


at this point in the call flow. This step is omitted for 


brevity. 


RLS in stockholm.example.org -> Local RLS 


SIP/2.0 200 OK 


Via: 


SIP/2.0/TCP pres.vancouver.example.com; 


branch=z9hG4bKFSrAF8CZFL 
To: <sip:adam-friends@stockholm.example.org>;tag=JenZ40P3 


From: 


Call- 


CSeg: 


<sip:adam@vancouver.example.com>;tag=al2eztNf 
ID: kBq5XhtZLN@pres.vancouver.example.com 
980774491 SUBSCRIBE 


Contact: <sip:stockholm.example.org> 
Expires: 3600 
Content-Length: 0 


11 


In this example, we assume that the RLS in stockholm.example.org 
is also an authority for presence information for the users in 
the "stockholm.example.org" domain. The NOTIFY contains an RLMI 
document describing the contained buddy list, as well as 
presence information for those users. In this particular case, 
the RLS in stockholm.example.org has chosen to sign [14] the 
body of the NOTIFY message. As described in RFC 3851, signing 
is performed by creating a multipart/signed document that has 
two parts. The first part is the document to be signed (in this 
example, the multipart/related document that describes the list 
resource states), while the second part is the actual signature. 
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RLS in stockholm.example.org -> Local RLS 


NOTIFY sip:pres.vancouver.example.com SIP/2.0 
Via: SIP/2.0/TCP pres.stockholm.example.org; 
branch=z9hG4bKmGL1nyZfQT 

Max-Forwards: 70 

From: <sip:adam-friends@stockholm.example.org>;tag=JenZ40P3 

To: <sip:adam@vancouver.example.com>;tag=al2ZeztNf 

Call-ID: kBg5XhtZLNGpres.vancouver.example.com 

CSeg: 294444656 NOTIFY 

Contact: <sip:stockholm.example.org> 

Event: presence 

Subscription-State: active;expires=3600 

Reguire: eventlist 

Content-Type: multipart/signed; 
protocol="application/pkcs7-signature"; 
micalg=shal;boundary="13WMZaaL8NpQWGnQ4mlU" 

Content-Length: 2038 


--13WMZaaL8NpQWGnQ4mlU 

Content-Transfer-Encoding: binary 

Content-ID: <ZPvJHL@stockholm.example.org> 

Content-Type: multipart/related;type="application/rlmi+xml"; 
start="<Cvjpeo@stockholm.example.org>"; 
boundary="tuLL131DyPZX0GMr2YOo" 


—-tuLL131DyPZX0GMr2YOo 

Content-Transfer-Encoding: binary 

Content-ID: <Cvjpeo@stockholm.example.org> 
Content-Type: application/rlmi+xml;charset="UTF-8" 


<?xml version="1.0" encoding="UTF-8"?> 
<list xmlns="urn:ietf:params:xml:ns:rlmi" 
uri="sip:adam-friends@stockholm.example.org" version="1" 
fullState="true"> 
<name xml:lang="en">Buddy List at COM</name> 
<name xml:lang="de">Liste der Freunde an COM</name> 
<resource uri="sip:joefstockholm.example.org"> 
<name>Joe Thomas</name> 
<instance id="1" state="active" 
cid="mrEakg@stockholm.example.org"/> 
</resource> 
<resource uri="Sip:mark@stockholm.example.org"> 
<name>Mark Edwards</name> 
<instance id="1" state="active" 
cid="KKMDmv@stockholm.example.org"/> 
</resource> 
</list> 
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—-tuLL131DyPZX0GMr2YOo 

Content-Transfer-Encoding: binary 

Content-ID: <mrEakg@stockholm.example.org> 
Content-Type: application/pidf+xml;charset="UTF-8" 


<?xml version="1.0" encoding="UTF-8"?> 
<presence xmlns="urn:ietf:params:xml:ns:pidf" 
entity="sip: joe@stockholm.example.org"> 
<tuple id="x823a4"> 
<status> 
<basic>open</basic> 
</status> 
<contact priority="1.0">sip: joe@stockholm.example.org</contact> 
</tuple> 
</presence> 


—-tuLL131DyPZX0GMr2YOo 

Content-Transfer-Encoding: binary 

Content-ID: <KKMDmv@stockholm.example.org> 
Content-Type: application/pidf+xml;charset="UTF-8" 


<?xml version="1.0" encoding="UTF-8"?> 
<presence xmlns="urn:ietf:params:xml:ns:pidf" 
entity="sip:mark@stockholm.example.org"> 
<tuple id="z98075"> 
<status> 
<basic>closed</basic> 
</status> 
</tuple> 
</presence> 


--tuLL131DyPZX0GMr2Y00-- 
--13WMZaaL8NpQWGnQ4mlU 
Content-Transfer-Encoding: binary 
Content-ID: <K9LB7k@stockholm.example.org> 
Content-Type: application/pkcs7-signature 
[PKCS #7 signature here] 


--13WMZaaL8NpQWGnQ4mlU-- 
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12. The Local RLS completes the NOTIFY transaction. 
Local RLS -> RLS in stockholm.example.org 


SIP/2.0 200 OK 

Via: SIP/2.0/TCP pres.stockholm.example.org; 
branch=z9hG4bKmGL1nyZfQT 

From: <sip:adam-friendststockholm.example.org>;tag=JenZ40P3 

To: <sip:adam@vancouver.example.com>;tag=al2ZeztNf 

Call-ID: kBq5XhtZLNfpres.vancouver .example.com 

CSeg: 294444656 NOTIFY 

Contact: <sip:pres.vancouver.example.com> 

Content-Length: 0 


13. At this point, the Local RLS decides it has collected enough 
additional information to warrant sending a new notification to 
the user. Although sending a full notification would be 
perfectly acceptable, the RLS decides to send a partial 
notification instead. The RLMI document contains only 
information for the updated resources, as indicated by setting 
the "fullState" parameter to "false". To avoid corrupting the 
S/MIME signature on the data received from the RLS in 
stockholm.example.org, the local RLS copies the entire 
multipart/signed body as-is into the notification that it sends. 


Local RLS -> Terminal 


NOTIFY sip:terminal.vancouver.example.com SIP/2.0 
Via: SIP/2.0/TCP pres.vancouver.example.com; 
branch=z 9hG4bK4EP1fSFOK1 

Max-Forwards: 70 

From: <sip:adam-buddies@pres.vancouver.example.com>;tag=zpNctbzq 

To: <sip:adam@vancouver.example.com>;tag=ie4hbb8t 

Call-ID: cdB34gLToCfterminal.vancouver.example.com 

CSeg: 997935769 NOTIFY 

Contact: <sip:pres.vancouver.example.com> 

Event: presence 

Subscription-State: active;expires=7200 

Require: eventlist 

Content-Type: multipart/related;type="application/rlmi+xml"; 
start="<2BEI83@pres.vancouver.example.com>"; 
boundary="TfZxoxgAvLggj4wRWPDL" 

Content-Length: 2862 


--TfZxoxgAvLqgj4wRWPDL 

Content-Transfer-Encoding: binary 

Content-ID: <2BEI83@pres.vancouver.example.com> 
Content-Type: application/rlmi+xml;charset="UTF-8" 
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<?xml version="1.0" encoding="UTF-8"?> 
<list xmlns="urn:ietf:params:xml:ns:rlmi" 
uri="sip:adam-friends@pres.vancouver.example.com" version="2" 
fullState="false"> 
<name xml:lang="en">Buddy List at COM</name> 
<name xml:lang="de">Liste der Freunde an COM</name> 
<resource uri="sip:ed@dallas.example.net"> 
<name>Ed at NET</name> 
<instance id="sdlkmeopdf" state="pending"/> 
</resource> 
<resource uri="sip:adam-friends@stockholm.example.org"> 
<name xml:lang="en">My Friends at ORG</name> 
<name xml:lang="de">Meine Freunde an ORG</name> 
<instance id="cmpqweitlp" state="active" 
cid="1KQhyE@pres.vancouver.example.com"/> 
</resource> 
</list> 


--TfZxoxgAvLqgj4wRWPDL 

Content-Transfer-Encoding: binary 

Content-ID: <1KOhyEGpres.vancouver.example.com> 

Content-Type: multipart/signed; 
protocol="application/pkcs7-signature"; 
micalg=shal;boundary="13WMZaaL8NpQWGnQ4mlU" 


--13WMZaaL8NpQWGnQ4mlU 

Content-Transfer-Encoding: binary 

Content-ID: <ZPvJHL@stockholm.example.org> 

Content-Type: multipart/related;type="application/rlmi+xml"; 
start="<Cvjpeo@stockholm.example.org>"; 
boundary="tuLL131DyPZX0GMr2Y00" 


—-tuLL131DyPZX0GMr2YOo 
Content-Transfer-Encoding: binary 
Content-ID: <Cvjpeo@stockholm.example.org> 
Content-Type: application/rlmi+xml;charset="UTF-8" 
<?xml version="1.0" encoding="UTF-8"?> 
<list xmlns="urn:ietf:params:xml:ns:rlmi" 
uri="sip:adam-friends@stockholm.example.org" version="1" 
fullState="true"> 
<name xml:lang="en">Buddy List at ORG</name> 
<name xml:lang="de">Liste der Freunde an ORG</name> 
<resource uri="sip:joefstockholm.example.org"> 
<name>Joe Thomas</name> 
<instance id="1" state="active" 
cid="mrEakg@stockholm.example.org"/> 
</resource> 
<resource uri="sip:mark@stockholm.example.org"> 
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<name>Mark Edwards</name> 
<instance id="1" state="active" 
cid="KKMDmv@stockholm.example.org"/> 
</resource> 
</list> 


—-tuLL131DyPZX0GMr2YOo 

Content-Transfer-Encoding: binary 

Content-ID: <mrEakg@stockholm.example.org> 
Content-Type: application/pidf+xml;charset="UTF-8" 


<?xml version="1.0" encoding="UTF-8"?> 
<presence xmlns="urn:ietf:params:xml:ns:pidf" 
entity="sip: joe@stockholm.example.org"> 
<tuple id="x823a4"> 
<status> 
<basic>open</basic> 
</status> 
<contact priority="1.0">sip: joe@stockholm.example.org</contact> 
</tuple> 
</presence> 


—-tuLL131DyPZX0GMr2YOo 

Content-Transfer-Encoding: binary 

Content-ID: <KKMDmvGstockholm.example.org> 
Content-Type: application/pidf+xml;charset="UTF-8" 


<?xml version="1.0" encoding="UTF-8"?> 
<presence xmlns="urn:ietf:params:xml:ns:pidf" 
entity="sip:mark@stockholm.example.org"> 
<tuple id="z98075"> 
<status> 
<basic>closed</basic> 
</status> 
</tuple> 
</presence> 
--tuLL131DyPZX0GMr2Y00-- 


--13WMZaaL8NpQWGnQ4mlU 
Content-Transfer-Encoding: binary 
Content-ID: <K9LB7kGstockholm.example.org> 
Content-Type: application/pkcs7-signature 
[PKCS #7 signature here] 
--13WMZaaL8NpQWGnQ4mlU-- 


--TfZxoxgAvLqgj4wRWPDL-- 
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14. The terminal completes the NOTIFY transaction. 
Terminal -> Local RLS 


SIP/2.0 200 OK 

Via: SIP/2.0/TCP pres.vancouver.example.com; 
branch=z9hG4bK4EP1fSFOK1 

From: <sip:adam-buddies@pres.vancouver.example.com>;tag=zpNctbzq 

To: <sip:adam@vancouver.example.com>;tag=ie4hbb8t 

Call-ID: cdB34qLToC@terminal.vancouver.example.com 

CSeg: 997935769 NOTIFY 

Contact: <sip:terminal.vancouver.example.com> 

Content-Length: 0 


7. Security Considerations 


Note that the mechanisms for obtaining state information for 
resources in a list are generally left to the RLS implementor. Some 
of the security issues below are specific to the circumstance in 
which a SIP back-end subscription is used for such a purpose. Non- 
SIP mechanisms for obtaining state information of resources in a list 
will typically have their own security issues associated with doing 
so; however, exhaustively enumerating such access methods is not 
possible in this document. Implementors using such mechanisms must 
analyze their chosen access methods for relevant security issues. 


7.1. Authentication 


If back-end subscriptions are required to retrieve resource state 
information, the end user is no longer the direct subscriber to the 
state of the resource. This means that direct authentication of the 
user is no longer possible. 


7.1.1. RLS and Subscriber in the Same Domain 


It is expected that the most common deployment of RLSes entails that 
the subscribers to the RLS will be in the same domain as the RLS. 
When this is the case, the RLS then has the ability to act as an 
authentication service. The role of authentication service is 
defined in "Enhancements for Authenticated Identity Management in the 
Session Initiation Protocol (SIP)" [7]. 


At a high level, under this system, the RLS authenticates the 
subscriber and then includes an "Identity" header field in all of the 
back-end subscriptions performed on behalf of that authenticated 
user. This "Identity" header field cryptographically asserts that 
the request has been authorized to be made on behalf of the user 
indicated in the "From" header field. 
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Because the ability to authenticate reguests is central to the proper 
functioning of the network, any RLS that uses SIP back-end 
subscriptions to acquire information about the resources in a 
resource list MUST be able to act as an authentication service as 
defined in [7], provided that local administrative policy allows it 
to do so. 


In other words, all RLS implementations that support back-end SIP 
subscriptions also must include the ability to be configured to 
act as an authentication service. Whether any given administrator 
chooses to activate such a feature is completely up to them. Of 
course, lacking the ability to act as an identity server, any RLS 
so configured will behave as described in the following section, 
since it is effectively acting as if it were in a different domain 
than the user. 


7.1.2. RLS and Subscriber in Different Domains 


In the general case, the SIP Authenticated Identity extensions do not 
provide a means for the RLS to securely assert that subscriptions are 
being performed on the end user's behalf. Specifically, when the 
subscriber and the RLS are in different domains, the RLS will have no 
means by which it can vouch for the user's identity. Mechanisms by 
which back-end subscriptions in such circumstances can be 
authenticated are left for future study. 


Until such general solutions are developed, RLSes that are in a 
different domain than the subscriber on whose behalf they are 
creating back-end subscriptions SHOULD subscribe to the resources 
using their own identity. By doing so, the RLS will generally obtain 
only the resource information that is made publicly available. 


Absent such general solutions, implementations of subscriber user 
agents MAY attempt direct subscriptions to resources in the resource 
list when subscribing to an RLS outside of their domain (either 
directly or by way of another resource list subscription). The 
resources to be subscribed to will be those indicated in the "uri" 
attribute of the <resource> elements present in the RLMI document 
returned by the RLS. Directly subscribing to the resources allows 
proper authentication of the user to take place, which will generally 
authorize them to receive more complete state information. 
Implementations that choose to perform such direct subscriptions 
SHOULD use the data retrieved instead of any information about the 
resource obtained via the list subscription. 
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7.2. Risks of Improper Aggregation 


A resource list server typically serves information to multiple 
subscribers at once. In many cases, resources may be present in 
several lists; additionally, it is guite possible that resource list 
servers will have two users subscribe to the same list. 


In these cases, misguided RLS implementations may attempt to minimize 
network load by maintaining only one back-end subscription to a 
resource in a list and presenting the result of such a subscription 
to more than one user. Of course, doing so circumvents any 
authorization policy that the notifier for the resource maintains. 
Keep in mind that authorization is often much more than a simple 
binary "allowed/not allowed" decision; resources may render very 
different -- and even conflicting -- resource states, depending on 
the identity of the subscribing user. 


To prevent the transmission of event information to anyone other than 
the intended recipient, implementations MUST NOT present the result 
of one back-end subscription to more than one user, unless: 


a. The RLS has adequate access to the complete authorization policy 
associated with the resource to which the back-end subscription 
has been made, AND 


b. The RLS can and has determined that presenting the information to 
more than one user does not violate such policy. 


Note that this is a very difficult problem to solve correctly. Even 
in the cases where such access is believed possible, this mode of 
operation is NOT RECOMMENDED. 


7.3. Signing and Sealing 


Implementors should keep in mind that any section of the MIME body 
may be signed and/or encrypted as necessary. Resource List Servers 
should take care not to modify any MIME bodies they receive from any 
back-end subscriptions, and should not generally rely on being able 
to read them. 


In order to facilitate security, resource list servers SHOULD pass 
along indication for support of "multipart/signed" and "application/ 
pkcs7-mime" content types to any SIP back-end subscriptions, if the 
subscriber includes them in the initial SUBSCRIBE message. Not doing 
so may actually result in resources refusing to divulge state (if 
notifier policy requires encryption, but the RLS fails to convey 
support), or subscribers discarding valid state (if subscriber policy 
requires a signature, but the RLS fails to convey support). 
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Note that actual implementation of encryption and signing by the RLS 
is not necessary to be able to pass through signed and/or encrypted 
bodies. 

7.4. Infinite Loops 
One risk introduced by the ability to nest resource lists is the 
possibility of creating lists that ultimately contain themselves as a 
sub-list. Detection and handling of such a case is trivial when the 
RLS services all the virtual subscriptions internally. When back-end 
subscriptions are created to service virtual subscriptions, however, 
detection of such situations becomes a more difficult problem. 
Implementors of RLSes that create back-end subscriptions MUST 
implement safeguards to prevent such nestings from creating an 
infinite loop of subscriptions. Typically, such mechanisms will 
require support in the back-end subscription protocol. In 
particular, applying filters to the back-end subscriptions can be an 
effective way to preclude such problems. 

8. IANA Considerations 

8.1. New SIP Option Tag: eventlist 


This section defines a new option tag for the registry established by 
Section 27.1 of RFC 3261[1]. 


Option Tag Name: eventlist 

Description: Extension to allow subscriptions to lists of resources. 

Published specification: RFC 4662 

8.2. New MIME type for Resource List Meta-Information 

MIME Media Type Name: application 

MIME subtype name:  rlmi+xml 

Required parameters: None 

Optional parameters: charset 
See RFC 3023 [12] for a discussion of the charset parameter on 
XML-derived MIME types. Since this MIME type is used exclusively 
in SIP, the use of UTF-8 encoding is strongly encouraged. 


Encoding considerations: 8-bit text 
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Security considerations: Security considerations specific to uses of 
this MIME type are discussed in RFC 4662. RFC 1874 [11] and RFC 
3023 [12] discuss security issues common to all uses of XML. 


Interoperability considerations: The use of this MIME body is 
intended to be generally interoperable. No unigue considerations 
have been identified. 

Published specification: RFC 4662 

Applications that use this media type: This media type is used to 
convey meta-information for the state of lists of resources within 


a Session Initiation Protocol (SIP) subscription. 


Additional information: 


Magic Number(s): None. 

File Extension(s): None. 

Macintosh File Type Code(s): None. 
Object Identifier(s) or OID(s): None. 


Intended usage: Limited Use 
Other Information/General Comment: None. 


Person to contact for further information: 
Name: Adam Roach 
E-Mail: adam@estacado.net 
Author/Change Controller: The specification of this MIME type is 
a work product of the SIMPLE working group and was authored by 
Adam Roach, Jonathan Rosenberg, and Ben Campbell. The IETF has 
change control over its specification. 


8.3. URN Sub-Namespace 
URI: urn:ietf:params:xml:ns:rlmi 


Description: This is the XML namespace URI for XML elements defined 
by RFC 4662 to describe information about subscriptions when such 
subscriptions are aggregated within a single SIP subscription. It 
is used in the application/rlmi+xml body type. 


Registrant Contact: 
Name: Adam Roach 
E-Mail: adam@estacado.net 
Author/Change Controller: The specification of this MIME type is 
a work product of the SIMPLE working group and was authored by 
Adam Roach, Jonathan Rosenberg, and Ben Campbell. The IETF has 
change control over its specification. 
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XML: 
BEGIN 
<?xml version="1.0"?> 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" 
"http://www.w3.org/TR/xhtml-basic/xhtml-basicl10.dtd"> 
<html xmlns="http://www.w3.org/1999/xhtml"> 
<head> 
<meta http-equiv="content-type" 
content="text/html;charset=utf-8"/> 
<title>Namespace for SIP Event Resource List 
Meta-Information</title> 
</head> 
<body> 
<hl>Namespace for SIP Event Resource List 
Meta-Information</h1> 
<h2>application/rlmi+xml</h2> 
<p>See <a href="[http://www.rfc-editor.org/rfc/rfc4662.txt]"> 
RFC4662</a>.</p> 
</body> 
</html> 
END 
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